बस फैक्टर स्कोर: टीम के विफल होने से पहले टीम के कितने सदस्य बस की चपेट में आ सकते हैं?

थोड़ा सा इतिहास

हालांकि शीर्षक काफी चरम लग सकता है, इसी तरह का एक वाक्य 1994 में माइकल मैकले द्वारा सार्वजनिक रूप से पूछा गया था:

अगर गुइडो एक बस से टकरा गया था? (गुइडो वैन रोसुम पायथन भाषा के निर्माता हैं)

उस प्रश्न के कारण बस फ़ैक्टर का निर्माण हुआ, जिसे बस समस्या, ट्रक फ़ैक्टर , लॉरी फ़ैक्टर या लॉटरी फ़ैक्टर के रूप में भी जाना जाता है।

"बस फैक्टर" क्या है?

जबकि वेब पर कई अलग-अलग परिभाषाएँ हैं, हम उन्हें इस प्रकार संक्षेप में प्रस्तुत कर सकते हैं:

बस फैक्टर उन लोगों की कुल संख्या है जिन्हें अक्षम होने की आवश्यकता होगी, जैसे कि बस की चपेट में आने से ताकि परियोजना मृत हो जाए।

इसे और अधिक वर्णनात्मक बनाने के लिए, बस फैक्टर स्कोर उन लोगों का अनुमान है जो आपके प्रोजेक्ट के लिए इतने महत्वपूर्ण हैं कि उनके बिना यह रुक जाएगा। यदि वे लोग किसी भी कारण से परियोजना से गायब हो गए (जैसे "दुर्घटना" या यहां तक कि छुट्टी लेना, निकाल दिया गया, या परियोजना छोड़ दी गई), तो कोई भी परियोजना को बनाए रखने में सक्षम नहीं होगा।

न्यूनतम संभव बस फैक्टर स्कोर सिर्फ 1 है, जिसका अर्थ है कि अगर एक व्यक्ति परियोजना छोड़ देता है तो यह रुक जाएगा या मर जाएगा। अधिक तकनीकी दृष्टिकोण से, इसे परियोजना के भीतर विफलता का एकल बिंदु माना जा सकता है। एक बहुत बड़ा बस फैक्टर स्कोर बेहतर है, लेकिन इसे हासिल करना हमेशा आसान नहीं होता है।

पीएचपी समुदाय समस्या

2021 के अंत में, PHP समुदाय को यह दुखद सूचना मिली कि असंख्य बग फिक्स, सुविधाओं और PHP को बनाए रखने के 10 वर्षों के बाद, मुख्य योगदानकर्ताओं में से एक: निकिता पोपोव ने पूरी तरह से अलग भाषा और समुदाय (रस्ट) में काम करने पर ध्यान केंद्रित करने का फैसला किया। & LLVM), जिसमें से वह पहले से ही कुछ वर्षों से अलग था।

पायथन भाषा के इतिहास के समान, उस निर्णय ने दिखाया कि PHP भाषा में इतने कम बस फैक्टर स्कोर के साथ वास्तव में एक बड़ी समस्या है। इसने उस भाषा के भविष्य को खतरे में डाल दिया है जो वेब के ~78% हिस्से को खतरनाक स्थिति में डाल देती है।

वर्तमान स्थिति को सुधारने के लिए, PHP पर काम करने वाले लोगों और कंपनियों ने सेना में शामिल होकर एक नई पहल शुरू की: PHP Foundation ।

PHP फाउंडेशन एक गैर-लाभकारी संगठन है जिसका मिशन PHP भाषा के लंबे जीवन और समृद्धि को सुनिश्चित करना है।

फाउंडेशन द्वारा किया गया पहला निर्णय नए डेवलपर्स को PHP कोर घटकों पर काम करने के लिए किराए पर लेना / प्रायोजित करना था। इस तरह वे बस फैक्टर स्कोर को सुरक्षित स्तर तक बढ़ाना शुरू कर सकते हैं। यह PHP के भविष्य को सुरक्षित और स्थिर बनाने के लिए समुदाय द्वारा उठाए जाने वाले कई कदमों में से एक है।

कंपनी की समस्याएं

स्टार्टअप्स से लेकर कॉरपोरेशन तक, जिन कंपनियों के लिए मैंने काम किया, उनमें से कई को अक्सर बस फैक्टर ने कड़ी टक्कर दी। उनकी कई टीमें (ज्यादातर समय जानबूझकर नहीं) एनआईएच (यहां आविष्कार नहीं किया गया) में गिर गईं, जिससे रखरखाव के साथ समस्याएं हुईं, और नए लोगों के लिए उच्च प्रवेश स्तर, क्योंकि अधिक से अधिक चीजें उन लोगों द्वारा बनाई गई थीं जो परियोजना छोड़ सकते थे किसी भी पल। इससे अक्सर उच्च तकनीकी ऋण होता है (जिसे मैं बाद की पोस्ट में समझाने की कोशिश करूंगा)।

कम बस फैक्टर स्कोर अक्सर तेजी से बढ़ते समय का हिस्सा होता है जब केवल कुछ डेवलपर्स ही अधिकांश कार्यक्षमता बनाते हैं जो बाद में तेजी से जटिल परियोजना के लिए आधार बन जाते हैं। ज्यादातर कंपनियां ऐसी ग्रोथ के दौरान बड़ी हायरिंग प्लान शुरू करती हैं, लेकिन ऐसा कुछ नहीं है जो सिर्फ बस फैक्टर को बढ़ा सके।

कम बस फैक्टर स्कोर कैसे बढ़ाएं?

कोचिंग सत्र और जोड़ी प्रोग्रामिंग

प्रत्येक नए सदस्य के पास उस परियोजना के वरिष्ठ लोगों में से एक के साथ जोड़ी प्रोग्रामिंग सत्र के कम से कम 30 मिनट होने चाहिए, जिसमें वह शामिल हो रहा है। ऐसे सत्रों के दौरान, एक कम अनुभवी व्यक्ति को अधिकांश कोडिंग करनी चाहिए, जबकि वरिष्ठ सलाहकार, उदाहरण के द्वारा नेतृत्व करते हैं और ऐसे भागों का सुझाव देते हैं जो कार्य के लक्ष्य को प्राप्त करने में मदद कर सकते हैं।

एक शिक्षक के रूप में आपका बस फैक्टर व्यक्ति

जब आप बस फैक्टर वाले लोगों की पहचान करते हैं, तो आपको इस बात पर ध्यान देना चाहिए कि वे आपकी परियोजना में उन सभी वर्षों के दौरान एकत्रित ज्ञान को कैसे साझा कर सकते हैं। उनका ज्ञान आपकी टीम के लिए सबसे बड़े मूल्यों में से एक है। क्या उन्होंने दस्तावेज़ीकरण लिखने, चीटशीट बनाने, आंतरिक प्रस्तुतियाँ करने और टीम के साथियों के साथ आमने-सामने के सत्रों में ज्ञान साझा करने पर अधिक ध्यान केंद्रित किया है। प्रोग्रामिंग पर उनका ध्यान कम किया जाना चाहिए।

कोड समीक्षा संस्कृति

जबकि कोड समीक्षा संस्कृति को अपनाना कोड गुणवत्ता और समीक्षा प्रक्रिया में सुधार के लिए टीमों द्वारा किया जाता है, कम स्पष्ट परिणाम परियोजना में लोगों के बीच प्रत्यक्ष ज्ञान साझा करना है। समीक्षा केवल स्वीकृति की मोहर देने की तरह नहीं होनी चाहिए। उन्हें यह बताना चाहिए कि कुछ इस तरह से क्यों किया गया, दूसरा नहीं, जिससे वरिष्ठों और टीम के अन्य साथियों के बीच रचनात्मक चर्चा हुई कि वरिष्ठों के दृष्टिकोण से अलग तरीके से क्या किया जा सकता है। समीक्षाओं को चर्चा की ओर ले जाना चाहिए।

परियोजना (ओं) की जटिलता को कम करना

अक्सर तेजी से बढ़ने वाली कंपनियों की समस्या तेजी से बढ़ने वाला तकनीकी ऋण होता है, जिससे कम बस फैक्टर स्कोर होता है। प्रभावी तकनीकों में से एक परियोजनाओं की जटिलता को छोटे, अधिक समर्पित लोगों में विभाजित करके कम करना है। यह निम्न प्रवेश-स्तर, तेजी से अपनाने और आसान रखरखाव की ओर जाता है। ये सभी बिंदु समग्र बस फैक्टर को काफी प्रभावी ढंग से बढ़ाने की अनुमति देते हैं। परियोजनाओं की जटिलता को कम करने के दौरान आपको सबसे बड़ी समस्या से बचना चाहिए, नए उप-परियोजना (ओं) में एक ही समस्या पैदा करने से बचने के लिए हमेशा टीमों (यहां तक कि छोटे वाले) को शामिल करना है।

टीम "फेरबदल"

यह बस फैक्टर स्कोर बढ़ाने का सबसे प्रभावी तरीका हो सकता है, लेकिन यह सबसे कठिन और खतरनाक भी है। टीम के मनोबल को खोने से रोकने के लिए आपको हर संभावना की गहराई से योजना बनाने की जरूरत है। "फेरबदल" के लिए बाध्य नहीं किया जाना चाहिए, लेकिन नियमित रूप से टीम के सदस्यों को प्रस्तावित किया जाना चाहिए, जैसे: हर दो तिमाहियों में एक बार; टीम के साथी टीम को बार-बार नहीं बदल सकते क्योंकि उन्हें एक नवागंतुक की तरह ऑनबोर्ड करने की आवश्यकता होगी। यदि सुनियोजित और क्रियान्वित की जाती है, तो आपकी टीमों को अन्य टीमों के साथ काम करते हुए सीखे गए ज्ञान को साझा करते हुए, विभिन्न डोमेन में अधिक व्यापक अनुभव प्राप्त होगा।

प्रशिक्षण बजट

आपके डेवलपर्स के लिए प्रशिक्षण बजट की योजना बनाना बस फैक्टर स्कोर को भी बढ़ा सकता है क्योंकि लोग व्यापक अनुभव प्राप्त करेंगे, और आपकी कंपनी पदानुक्रम के भीतर प्रत्येक वरिष्ठता रैंक में अधिक लोगों को रखने के लिए आपकी टीम का विस्तार करेंगे।

सारांश

अपनी टीम के बस फ़ैक्टर स्कोर को बढ़ाना इतना आसान, सस्ता या तेज़ नहीं है। ऐसे मामले हैं जब आप आसानी से उस स्कोर को नहीं बढ़ाना चाहते (या नहीं भी कर सकते हैं), उदाहरण के लिए जब परियोजना में संवेदनशील डेटा होता है और आप इसे संभालने के लिए अपने नए कर्मचारियों पर भरोसा नहीं कर सकते हैं। लेकिन अब आप कुछ मूलभूत बातें जानते हैं जो एक "बस दुर्घटना" के कारण आपके परिचालन को रुकने से रोकने में आपकी मदद कर सकती हैं।